Tech Arsenal 1

home *** CD-ROM | disk | FTP | other *** search

/ Tech Arsenal 1 / Tech Arsenal (Arsenal Computer).ISO / tek-05 / pktmux11.zip / PKTMUX.DOC < prev next >

Wrap

Text File | 1992-05-01 | 71KB | 1,486 lines

/* C:\DOC\PKTMUX.DOC ***** 1 MAY 92 ** 11:25 ******; G W Robinson R A L I B M P C U S E R G U I D E ----------------------------------------- PKTMUX Packet Driver Multiplexor -------------------------------- Contents ======== 1. Introduction and Disclaimer 2. Installation 3. Overview 4. Usage Guidelines 5. Program Description 5.1 PKTMUX.EXE 5.2 PKTDRV.EXE 5.3 PKTSTATS.EXE 5.4 WINPKT.COM 6. Examples 6.1 Packet Driver, PCTCP and PC-NFS Applications under DOS 6.2 MOS2 under DOS 6.3 Packet Driver Applications under Windows 3 6.4 Packet Driver, PCTCP and PC-NFS Applications under Windows 3 6.5 Windows 3 Applications 7. Technical Description 7.1 Basic Methodology 7.2 Buffer Strategy 7.3 Control Programs 7.4 Listeners and /l Options 7.5 Port Duplication 7.6 IP Fragmentation 7.7 Other IP Protocols 7.8 Channel Management 8. Problem Solving 9. Bugs/Features and Problem Programs 10. Differences in PKTMUX versions 11. Support 12. References 1. Introduction and Disclaimer ============================== The author and his employers accept no responsibilty for any damage done by this software. It is run strictly at the user's risk and all necessary precautions, such as backing up of discs, should be taken before hand. Similarily the vendors/authors of applications and Packet Drivers accept no responsibility for problems and malfunctions, and will give no support, when their software is used with PKTMUX. This document describes PKTMUX which is a program that provides a multiplexing interface to a Packet Driver. It thus allows several IP protocol stacks to be run in parallel either under DOS or a control program such as Windows 3 or DESQview. Multiplexing IP protocol stacks is a non trivial problem and this program is only likely to meet about 90% of user requirements. There will always be 10% who need a more sophisticated product. Because PKTMUX makes certain probability assumptions it is also highly likely that it will make a mistake every now and then when they are not valid. At best an application will recover from this situation and at worse something, possibly even the whole PC, will fail. It is therefore likely that PKTMUX will never be 100% reliable and in some situations it may be so flakey as to be unusable. This documents version 1.1, which is the first release with some bug fixes and minor enhancements. The programs from this version must not be mixed with those from version 1.0 as they are incompatible. Further details of the differences are given at the end of this document. 2. Installation =============== The system comes as a single program named PKTMUXxx.EXE where xx is the version number, currently 11. When this program is run it expands into several files. These are: PKTMUX.EXE The packet multiplexor PKTDRV.EXE The pseudo Packet Driver interface to PKTMUX PKTSTATS.EXE A program state and statistics display program PKTMUX.DOC This documentation In addition a free program WINPKT.COM and a source listing WINPKT.ASM is supplied since this provides some of PKTMUX's functionality and is rather smaller. The programs should be copied into a directory in the Path such as C:\BIN on RAL machines. PKTMUX.DOC should be put in a documentation directory such as C:\DOC on RAL machines. The BAT file INSTALL.BAT does this. 3. Overview =========== The Packet Driver interface was developed by FTP Software Inc as a standardised way of accessing different makes of communications cards. It is widely used especially over ethernets and a large amount of communications software is available for it. The ethernet implementation makes use of the fact that two bytes in the header define the packet type and this is used to provide a multiplexing mechanism between several packet types. However it looks no further into the protocol stack and thus this feature is of limited use when protocols of the same type, such as those from the TCP/IP family, are used. PKTMUX attempts to remove this limitation by providing a multiplexing facility for Internet Protocols (IP). This is done by not only switching on the packet type (which denotes IP) but also the IP protocol type (which can denote IP protocols TCP, UDP, ICMP and others). In the case of TCP and UDP it can also switch on the Port number being used. It is therefore possible to run more than one IP protocol stack at the same time. It is not possible to multiplex other protocol stacks or more than one of each IP protocol type other than TCP, UDP or ICMP. PKTMUX was originally written to meet the needs of the RAL MOS2 program which is a TSR (Terminate and Stay Resident) program that provides IBM 3270 emulation over asynchronous and ethernet communications. In this context it provides two functions for the TCP/IP version of MOS2. On is that it allows additional communications applications to run alongside MOS2. This is useful because, since MOS2 is a TSR, you can hot key back to DOS and run other commands. Thus an LPR or FTP can be run alongside the MOS2 3270 session. A second requirement was to allow MOS2 to run under a control program such as Windows 3 or DESQview. This is an instance of a more general problem in running an application which uses a Packet Driver under a control program. It arises because the Packet Driver, which is loaded before Windows, calls the application when it has received a packet. This is quite satisfactory under DOS but under Windows there is no certainty that the application is currently running and there is therefore the risk of jumping into the middle of another program with dire consequences. A Packet Driver option -w gets over this by checking that part of the application program code is present and throwing away the packet if not. This leads to a rather slow data rate as the protocol timeout and retry mechanisms have to be brought into play to recover from the situation. A better solution is provided by the free software WINPKT which only works under Windows 3 Enhanced mode and uses Windows 3 facilities to make sure the application is running. A copy of WINPKT is provided in this package. WINPKT has the drawback that it does not work with other control programs such as DESQview and also with certain ethernet cards such as the BICC 16 bit varient. PKTMUX meets this requirement and gives the additional feature of being able to run communications applications in more than one window. Given the widespread use of Packet Driver it is surprising that nobody has written a PKTMUX before. It is probably because a general purpose multiplexor is impossible to implement. PKTMUX only attempts to meet the needs of IP protocols and is therefore likely to be of little use in other situations. It must however be emphasised that PKTMUX will only work when the probability of various identifying values being duplicated is low and that when duplication does occur then the various retry mechanisms can recover from the mess. If this is not the case the PKTMUX is of little use. PKTMUX has so far been tested satisfactorily with PCTCP, PC-NFS, CUTCP and Waterloo TCP. It also works over the RAL LLCPKT2 program. Further technical details are given in the Program and Technical Description sections. 4. Usage Guidelines =================== The following give basic usage guidelines. For more detail consult the Program Descriptions and Examples sections. All programs except give help when run with the /h option. The normal procedure for running a communications application is to load a Packet Driver and then run the application. To introduce multiplexing into this PKTMUX and PKTDRV must be loaded after the Packet Driver and before the application. Thus under DOS type the following after you have loaded the Packet Driver: PKTMUX n ; n is the maximum number of packet ; driver channels to support - default 2 PKTDRV ; repeated n times - displays Interrupt ; used Then run the applications as required. Note the first ones must usually be TSRs otherwise you cannot get back to DOS to load subsequent applications. Applications which search for a Packet Driver will find the first free PKTDRV. Once an application starts using PKTDRV it becomes busy and is no longer recognised as a Packet Driver. Note that this only happens once the application has started communicating over the network so each application must be got to this state before further applications are loaded. If not then two applications will link into the same PKTDRV. Applications for which you have to specify the Packet Driver Interrupt should be set for the highest PKTDRV Interrupt to avoid conflicts. For usage under a control program such as Windows 3 run PKTMUX as above but dont run PKTDRV until after the control program is active. Then run one copy of PKTDRV in any DOS session from which you wish to use a communications application that runs over a Packet Driver. For applications that run directly under Windows 3 (eg WINQVT) either use WINPKT or, if further packet driver channels are required, then run PKTMUX as above and then one PKTDRV before Windows 3 is loaded. Then start up the Windows application which will use this PKTDRV. Further applications running in DOS sessions must have their PKTDRV loaded before they are run. The program PKTSTATS gives details of program states and various statistics. 5. Program Descriptions ======================= 5.1 PKTMUX.EXE -------------- This is a TSR that provides, in conjunction with PKTDRV, multiple IP protocol channels to a Packet Driver. Its format is: PKTMUX chan_cnt pkt_drv_int chan_time_out /options which installs the multiplexor on the first packet driver it finds or hex interrupt "pkt_drv_int" is this is specified (note 1). "Chan_cnt" channels are supported - default is 2 (note 2). "chan_time_out" is the time in seconds a timed out channel waits before being reset (note 6). PKTMUX memory usage ranges from 13K for one channel to 20K for four channels. The following options modify the action taken: a display additional information on loading. d drop packets if application has no buffers (note 5). o override use of specified interrupt (note 1). h display this help information. r reset timed out channels; rr resets internal flags as well and should be used with care (note 6). t terminate PKTMUX and Packet Driver (note 3). u unload PKTMUX if not being used by a PKTDRV (note 3). x multiplex all received packets - testing only (note 7). 1 to 9 allocate buffers for this channel count (note 4). Examples are: pktmux ; normal use - 2 channels pktmux 4 ; install to multiplex four applications pktmux 2 62 ; install on Packet Driver at Int 62 pktmux /u ; unload PKTMUX (dont forget to unload ; PKTDRVs first) pktmux 4 /2 ; install to multiplex four applications but ; only allocate enough buffers for two pktmux /r ; reset timed out channels Notes: 1. By default PKTMUX searches for a Packet Driver and, on finding one, takes over its interrupt effectively hiding it so it cannot be found by any other application. There is then no confusion between the real Packet Driver and the pseudo ones provided by PKTDRV. Note that PKTMUX will refuse to load if during its search for a Packet Driver either another PKTMUX or a PKTDRV is found or if one of these is the specified pkt_drv_int. This latter restriction can be overcome by the /o (override) option. 2. By default PKTMUX supports two Packet Driver channels. This means it will communicate with up to two copies of PKTDRV and provide two pseudo Packet Driver interfaces. Each PKTDRV acts, within limits, as if it were a Packet Driver with its own ethernet card albiet with the same MAC address as any others. PKTMUX supports up to four busy copies of PKTDRV. Note that supporting only one channel achieves the same effect as a normal Packet Driver and is only useful where PKTMUX provides additional functionality such as allowing an application to run under Windows 3. 3. The /u option causes PKTMUX to unload unless a PKTDRV is still busy. The /t option does the same thing but also sends a terminate request to the Packet Driver, which will also unload if it supports this facility. 4. By default PKTMUX allocates a basic set of buffers and then adds an additional one to each size group for each channel. Tests suggest this is adequate for most cases. However this can be overridden by giving /n where n is a decimal number in the range 0 to 9. PKTMUX will then allocate buffers as if this number of channels were to be used. This can be used to either save memory by reducing the buffer allocation or increasing the number of buffers when experience suggests it is needed. The memory overhead per channel is a little over 2K. The buffer allocation is shown by PKTMUX when it is loaded and in detail by running PKTSTATS /a after PKTMUX has been loaded. 5. PKTMUX does its best to avoid losing data by holding packets in its buffers when an application is unable to accept them. In some cases this can cause a shortage of buffers. The /d (drop) option causes PKTMUX to behave exactly as a Packet Driver and to drop any packet that is refused by an application because it has insufficient buffer space. This option acts on all channels and overrides a similar option on PKTDRV which works on a per channel basis. 6. When running under Windows 3 or DESQview with a PKTDRV and the application in a DOS session then, if the session is terminated without closing down the application, PKTMUX is left with the channel marked as Busy. It will either be freed after "Chan_time_out" seconds (default infinity) or the option /r (reset) can be used on a call to PKTMUX to reset all such channels. If /rr is given then the busy flags in PKTMUX are also reset which could cause it to fail. See also the PKTDRV /r option and the section on Channel Management in the Technical Description below for further details. 7. By default PKTMUX sends data direct to the application when only one channel is in use. If the /x option is given then packets are copied to a buffer and multiplexed by the normal mechanisms as if several channels were operational. This is therefore a test facility to check if PKTMUX is able to support an application irrespective of any other application that is running. 5.2 PKTDRV.EXE -------------- This is a TSR which provides the pseudo Packet Driver interface in conjunction with PKTMUX. Its format is: PKTDRV pkt_drvr_int mux_int all_type /options which uses the multiplexor on hex interrupt "mux_int" or by default searches for it. It installs itself as a Packet Driver on hex interrupt "pkt_drvr_int" or, by default, the first free interrupt after the multiplexor (note 1). The "all_type" parameter (repeatable) defines the packet TYPE values used when an application asks for all types (eg PC-NFS). The default setting is 0800 and 0806 (note 2). PKTDRV memory usage is a little over 1K. The following options modify the action taken: c copy send buffers (note 3). d drop packets if application has no buffers (note 5). f force PKTDRV to be Free; !f forces to Busy (note 1) h display this help information. l act as listener for any protocol type (note 4). !l dont act as listener for any protocol type. lf act as listener for TCP FTP; !lf negates. li act as listener for IP; !li negates. lt act as listener for TCP; !lt negates. lt# act as listener for TCP port # (decimal); !lt# negates. lu act as listener for UDP only; !lu negates. lu# act as listener for UDP port # (decimal); !lu# negates. r reset a PKTDRV that is busy (note 1). t terminate PKTDRV, PKTMUX and Packet Driver (note 6). u unload last loaded PKTDRV if Busy (note 6). uu unload last loaded PKTDRV even if Busy. ur repeatedly unload last loaded PKTDRV if not Busy. Examples are: pktdrv ; normal use pktdrv /c ; copy send buffers pktdrv 66 62 ; multiplexor on 62, put Packet Driver on 66 pktdrv /t ; terminate PKTDRV, PKTMUX and Packet Driver pktdrv /u ; unload last PKTDRV to be loaded pktdrv /uu ; unload last PKTDRV to be loaded even if Busy pktdrv 63 /u ; unload PKTDRV on Int 63 pktdrv 0 0 800 806 1000 ; Application wanting all packet types will ; just get 0800, 0806 and 1000 pktdrv /!l /lf ; not a listener for any service except FTP pktdrv /lt21 ; listener for TCP port 21 Notes: 1. PKTDRV by default uses the next free Interrupt after that used by PKTMUX. It avoids Interrupts 61, 62 and 64, as these are used by PCTCP, Vista eXceed and Novell respectively, and also 67 as this is the EMS entry point. Interrupts 70 - 76 are normally in use on all but the XT type PCs. Note that under a control program, such as Windows 3, PKTDRV will, by default, use the same Interrupt in each DOS session it is loaded in. This is because each DOS session has its own version of the Interrupts. For the same reason PKTSTATS will only see the PKTDRV, if any, in the DOS session yet will display the correct total that are busy. Part of the Packet Driver definition is the use of the string PKT DRVR just after the interrupt entry point in order to identify it. A communications application which does not require the explicit definition of the Packet Driver interrupt searches from Interrupt 60 up to 80 until it finds one. PKTDRV uses the same mechanism and so appears to be a genuine Packet Driver. However once a communications application has accessed PKTDRV the identification is changed and only reverts back when the application has given a release command. Thus several copies of PKTDRV can provide the impression that multiple Packet Drivers are present. The state of each PKTDRV is shown by calling PKTSTATS - Free means it can be used by an application and Busy means its identification has been changed and it is in use. One problem with this mechanism is when two applications can use the same Packet Driver - for example PCTCP running alongside a Novell Packet Driver - then doing this over PKTDRV will fail. One solution is to use separate PKTDRV for each. Alternatively once the first application has been started and the PKTDRV is now Busy then a command of the form: pktdrv pkt_drvr_int /f forces the state back to Free. A second application can then be loaded which finds PKTDRV and can use it. The opposite problem is when an application is loaded, locates a Free PKTDRV but does not issue any commands and thus change the PKTDRV state to Busy. The call: pktdrv pkt_drvr_int /!f forces the PKTDRV to be Busy thus subsequent applications will not find it. If a PKTDRV is marked as Busy and the application has terminated (or crashed!) then calling PKTDRV with /r option will reset the specified "pkt_drvr_int" PKTDRV. Note that /r resets the channel whereas /f simply resets the program identification and leaves all the call details intact. If the PKTDRV was also terminated at the same time as the application, such as when a Windows DOS session is terminated, then the channel is Busy but there is no PKTDRV to send a Reset to. In this case PKTMUX will have registered that the PKTDRV has gone and giving the command: pktmux /r will reset any Busy channel for which there is no PKTDRV. Note in the three PKTDRV calls if the "pkt_drvr_int" is not specified then a search is made from the last possible PKTDRV Interrupt number (80) back to the first (60). Thus a generalised use of the feature is possible provided the PKTDRV being used is the last one that was loaded and/or the highest Interrupt number. A copy of PKTDRV can be loaded at any time. If it is required to unload the system at some later time it is perhaps wise to load all the PKTDRV copies that are required under DOS just after PKTMUX. This minimises the chance of problems with interrupt chains but means that any use of the /f or /r options need the "pkt_drvr_int" specifying. 2. Instead of requesting certain packet types some applications, notably PC-NFS, ask for all packet types. PKTMUX does not allow this since it makes its job extremely difficult so PKTDRV intercepts such a request and replaces it by specific packet types. By default these are 0800 (IP Protocols) and 0806 (ARP - Address Resolution Protocols) and these are all PC-NFS really needs for its own use. Where further packet types are required these can be overridden and alternatives supplied. One limitation of this implementation is that an application with a genuine requirement for all packet types cannot be supported. An example is IEEE 802.3 (ISO 8802/3) where the packet type field is used as the packet size. Thus implementations of ISO CONS (Pinkbook in the UK academic community) cannot run over PKTMUX. Users of the UK Academic community's RAINBOW software who wish to use TCP/IP alongside it should run the RAL LLCPKT2 product which provides a packet driver interface. This interface can then be either used directly by an application or via PKTMUX for several applications. Note however that the overheads are significant. 3. Under Windows 3 (and possibly DESQview) some communications cards which use DMA (direct memory access) for sending data don't work properly. The same thing can happen when the application is located in upper memory (ie above 640K). The solution is to copy the data from the application's buffer into one in PKTMUX and send it from there. This is done by the /c option and it only applies to data sent via that PKTDRV. The only card so far found to require this is the BICC 16bit ethernet card though this may be dependent on the PC hardware and the EMM in use. 4. The /l and /!l options indicate whether or not the application using this PKTDRV should act as a listener for well known services. See Technical Description below for further details. 5. The /d (drop) option makes this PKTDRV channel behave as a normal Packet Driver and drop any packet for which the application has no buffer rather than holding it in a buffer which is the default. The PKTMUX option /d implements the same feature for all channels and overrides the PKTDRV setting. 6. The /u option causes PKTDRV to unload unless it is still busy with an application. Adding an /r requests all PKTDRVs be unloaded. Note this may not be possible if other TSRs where loaded between PKTDRVs. If it is known that an application is not Busy, such as when it has crashed, then the /uu option will force the unload. The /t option does the same thing but also sends a terminate request to PKTMUX which, if it is acceptable, will also send a terminate request to the Packet Driver. If the "pkt_drvr_int" is not specified then a search is made from the last possible PKTDRV Interrupt number (80) back to the first (60). Thus a generalised use of this feature is only possible provided the PKTDRV being unloaded is the last one that was loaded and also the highest Interrupt number. 5.3 PKTSTATS.EXE ---------------- This program displays program details and statistics from PKTMUX. Its format is: PKTSTATS /options The following options modify the action taken: a display further information - can be repeated (note 1). h display this help information. Examples are: pktstats ; normal use pktstats /a ; show further information Notes: 1. The option /a can be repeated up to 3 times to give increasing levels of information. This is mainly intended for debugging purposes. Repeating /a 3 times can get the program in a loop or give misleading information since it scans queues which may be changing. This is intended only for cases when PKTMUX has stopped with a system error. 2. The counts given by PKTSTATS are 16 bit integers so will overflow over a period of time. 3. In the output from PKTSTATS where the name before a count value is in CAPITAL letters then this indicates that data is being lost or discarded for some reason. Further details are given in the section on Problem Solving. 5.4 WINPKT.COM -------------- This program is not part of the PKTMUX system but since it provides a subset of the facilities for a smaller memory requirement it is included. In is not supported by RAL. In accordance with the distribution licence the source is also supplied in WINPKT.ASM. The program COPYING mentioned at start up is not supplied as I dont have a copy. WINPKT acts as an interface between an application running under Windows 3 in Enhanced mode and a Packet Driver. It uses Windows 3 calls so is specific to this case. Its format is: WINPKT new_pkt_drvr_int old_pkt_drvr_int where "old_pkt_drvr_int" is the interrupt of the Packet Driver in either decimal or hex preceeded by 0x. "new_pkt_drvr_int" is the new interrupt to use and cannot be the same as "old_pkt_drvr_int". There are no documented options. Examples are: winpkt 0x63 0x64 ; Packet driver on Interrupt 64, WINPKT ; accessed via Interrupt 63 winpkt ; provide help information Notes: 1. WINPKT should be loaded after the Packet Driver and before Windows 3 is loaded. It is recommended that "new_pkt_drvr_int" is before "old_pkt_drvr_int" since applications that search for a packet driver will find the driver and not WINPKT. 2. WINPKT has no unloading mechanism so if unloading is required the RAL LOADSYS system or similar must be used. 3. WINPKT may not work with certain ethernet cards. The BICC 16 bit card is the only know example so far found. PKTMUX should be used in these cases along with the /c option on PKTDRV. 6. Examples ============ The following examples illustrate the use of PKTMUX and attempt to show the various possible uses of the system. It assumes a degree of familiarity with setting up and use of the various systems exampled. Examples include the RAL MOS2 IBM 3270 emulator since this system was one of the reasons for writing PKTMUX. The RAL LOADSYS program to load and unload TSRs and Device Drivers can also be useful in running multiple protocol stacks. Details of both are given in the Reference Section. In general there are two classes of communications applications. The simplest are those that just need a Packet Driver in order to work, for example the CUTCP programs PING, LPR and FTPBIN. A more complicated type are those applications which require their own TSR to be loaded first. The applications then communicate via this instead of directly to the Packet Driver. Examples are applications that run over PCTCP and PC-NFS. Another twist are those applications that either are, or can become, TSRs and thus allow you to return to DOS. Thus further applications can be run. Examples are MOS2 which is a TSR and FTP which via the command ! becomes a TSR and starts up a DOS session. 6.1 Packet Driver, PCTCP and PC-NFS Applications under DOS ---------------------------------------------------------- The following illustrates how to run a Packet Driver application alongside those requiring their own TSR to be loaded. The first is for PCTCP and assumes IPCUST.SYS and IFCUST.SYS are loaded in CONFIG.SYS. ne2000 0x63 0x5 0x320 ; Load Packet Driver for NE2000 card pktmux ; Support 2 channels pktdrv ; PKTDRV for PCTCP to use pktdrv ; PKTDRV for Packet Driver application ; to use ethdrv ; PCTCP Packet Driver interface You can now run applications from the PCTCP program suite, such as FTP, PING or LPR. Programs that just require a Packet Driver can also be run such as FTPBIN from the CUTCP program suite. The following illustrates how to run a Packet Driver application alongside the PC-NFS TSR. It is assumed that SOCKDRV.SYS, PKTD.SYS and ANSI.SYS are loaded in CONFIG.SYS. pcnfs.sys /b1 ; loaded in CONFIG.SYS mbdndpd 0x63 /I10 /D3 ; Load Packet Driver for BICC 16 bit ; card pktmux ; Support 2 channels pktdrv ; PKTDRV for PC-NFS to use pktdrv ; PKTDRV for Packet Driver application cd \nfs prt * ; Normal PC-NFS loading nfsrun PC-NFS applications such as NFSPING can now be run as well as those just requiring a Packet Driver such as FTPBIN from CUTCP. 6.2 MOS2 under DOS ------------------ The RAL MOS2 IBM 3270 Emulator v2.3 is a TSR. It supports the Waterloo TCP/IP protocol stack and is normally run by loading the Packet Driver and then running the file MOS2T.BAT. To achieve this using PKTMUX type: ne2000 0x63 0x5 0x320 ; Load Packet Driver pktmux ; Support 2 channels pktdrv ; PKTDRV for MOS2 to use pktdrv ; PKTDRV for applications to use mos2t ; Run MOS2 Once MOS2 is running you can then hot key (Alt-Esc) back to DOS and then any other communications application which runs over a Packet Driver can be used. For example PING from the Waterloo TCP/IP suite or FTPBIN or LPR from the CUTCP suite. For example: ftpbin ib ; establish FTP communications with IB To run MOS2 alongside applications from the PCTCP applications suite the following is suggested: ne2000 0x63 0x5 0x320 ; Load Packet Driver pktmux ; Support 2 channels pktdrv ; PKTDRV for PCTCP to use pktdrv ; PKTDRV for MOS2 to use ethdrv ; PCTCP Packet Driver interface mos2t ; Run MOS2 Once MOS2 is running the PCTCP applications can be used. A combination of the two cases, that is the ability to run applications from the PCTCP program suite or any other application that runs directly over a Packet Driver can be achieved by the following: ne2000 0x63 0x5 0x320 ; Load Packet Driver pktmux 3 ; Support 3 channels pktdrv ; PKTDRV for PCTCP to use pktdrv ; PKTDRV for MOS2 to use pktdrv ; PKTDRV for applications to use ethdrv ; PCTCP Packet Driver interface mos2t ; Run MOS2 Once MOS2 is running either the PCTCP applications or those requiring a Packet Driver can be used. Note that it is possible to run MOS2 before loading PCTCP but this is not recommended. Loading PCTCP first removes any problems with the provision of well known services such as an FTP listener. If MOS2 must be loaded first then its PKTDRV should have the /!l option so that any incoming calls for well known services are routed to the next PKTDRV which should be the one for PCTCP. 6.3 Packet Driver Applications under Windows 3 ---------------------------------------------- The following illustrates how to run Packet Driver applications under Windows 3. Use under DESQview is very similar. ne2000 0x63 0x5 0x320 ; Load Packet Driver pktmux 4 ; Support 4 channels win ; Run Windows 3 To run an application open a DOS session and type: pktdrv ; PKTDRV for application to use followed by the application. The application could be the MOS2 emulator BAT file for example: mos2t To run further applications just open more DOS sessions and run PKTDRV then the application. However be warned that Windows 3.0 can become unstable if you have insufficient memory and opening too many DOS sessions may result in a Unrecoverable Application Error. This usually does no damage and other sessions are unaffected. Note also that, unless the PC is quite powerful, applications may fail as they will not get enough CPU to process their communications in time and protocols may time out. 6.4 Packet Driver, PCTCP and PC-NFS Applications under Windows 3 ---------------------------------------------------------------- This is essentially the same as under DOS but with the PKTDRV for the Packet Driver application run under a DOS session. For example to run both PCTCP and Packet Driver applications the following would suffice. ne2000 0x63 0x5 0x320 ; Load Packet Driver pktmux 4 ; Support 4 channels pktdrv ; PKTDRV for PCTCP to use ethdrv ; PCTCP Packet Driver interface win ; Run Windows 3 To run a Packet Driver application open a DOS session and type: pktdrv ; PKTDRV for application to use followed by the application. For PCTCP applications just run the application. 6.5 Windows 3 Applications --------------------------- Windows 3 applications are slightly different in that they do not run in a DOS session so it is not possible to run PKTDRV after Windows has been loaded. For those that run over PCTCP or PC-NFS then the appropriate TSR is loaded under DOS after PKTMUX and one PKTDRV as illustrated above. The application is then run under Windows as normal. For those that run over a Packet Driver, for example WINQVT, then the procedure is very similar to running them under DOS, that is the PKTDRV is loaded before Windows 3. For example to run WINQVT and also other applications that use a Packet Driver the following would suffice: ne2000 0x63 0x5 0x320 ; Load Packet Driver pktmux 4 ; Support 4 channels pktdrv ; PKTDRV for WINQVT to use pktint ; WINQVT Packet Driver interface win ; Run Windows 3 Then run WINQVT as normal with QVT_TCP.RC edited to contain the line: packet_vector=65 This is done because WINQVT has to have its Packet Driver interrupt specified and PKTDRV will use 65. If there is any doubt then PKTDRV could have its interrupt number specified as the first parameter for example: pktdrv 65 If several PKTDRVs had been loaded it would be better to give the one for WINQVT a high interrupt number (eg 7F) to guarantee it will be free. To run further Packet Driver applications open a DOS session and run PKTDRV and the application as before. To run PCTCP or PC-NFS applications then modify the above to include the TSR before loading Windows. Alternatively for PCTCP the TSR can be run under Windows 3 inside a DOS session since it is effectively a Packet Driver application. IPCUST.SYS and IFCUST.SYS must have previously been loaded in CONFIG.SYS or could be loaded by the RAL LOADSYS system. 7. Technical Description ========================= This section describes how PKTMUX goes about its task and is intended for those who wish to understand how the system works and why it has the limitations it has. An understanding of the Packet Driver interface is assumed. The various PKTMUX counts and states detailed below are shown the command: pktstats /a Additional states are given by the option /aa. 7.1 Basic Methodology --------------------- In essence the system is very simple. PKTMUX talks to the Packet Driver and receives data from it. Each PKTDRV passes all commands onto PKTMUX with the addition of the channel number. PKTDRV also sits on a timer interrupt and asks PKTMUX once per system tick if there are any packets for this channel and if so then gets them passed over. A PKTDRV is only Busy from when it has been asked by an application to Assign a packet type to when that is Released. In between it remains Free. Whilst PKTMUX makes every attempt to be efficient it does create a significant overhead when multiplexing between several applications. This is because the Packet Driver interface only tells you it has a packet and does not give a pointer so that you can see if you are interested in its contents. Where only one application is using this packet type then the packet is sent direct to the application. Otherwise it is necessary for PKTMUX to read the packet into its own storage, analyse its contents and then send it when asked by a PKTDRV to the appropriate application(s). Thus every packet received in this manner has to be copied once more than necessary. 7.2 Buffer Strategy ------------------- When an application is unable to accept a packet, usually because it has no free buffer space, then PKTMUX keeps the packet in its buffers and every timer tick keeps asking the application to accept it. It does this even when it normally sends data direct to the application, thus those applications which operate on a small buffer pool may lose less data when under PKTMUX especially when they receive less CPU cycles when running under Windows 3. The decision whether to keep a packet when an application is unable to accept it is a difficult one and depends on the available buffer pool and activity on other channels. The ultimate criterion is the age of the buffer and after between 2 and 3 seconds it is dropped. Whilst this mechanism is satisfactory for most applications there are some that give problems. One that has been noted is TRUMPET which, when an interaction has been completed and it is waiting for user input, refuses to accept any more packets. Whilst PKTMUX's buffer strategy will cope in normal circumstances, under heavy loading this could give problems. The /d option is therefore available on PKTDRV which causes a packet to be always dropped when an application is unable to accept it. Thus it behaves exactly as a Packet Driver. The /d option is also available on PKTMUX to provide this feature on all channels and could be used in cases of extreme loading. All packets dropped because the application cannot accept them are counted as LOST in the PKTSTATS figures for each PKTDRV channel. 7.3 Control Programs -------------------- One of the problems with the Packet Driver interface is that when it receives a packet it then calls a routine in the application. This will not fail under DOS but if the application is running under a control program such as Windows 3 or DESQview, where the application can be swopped in and out of the current virtual memory, then there is a need to establish that the current application is the correct one. PKTMUX does this by noting the code it is to jump to when a packet is received and checking if that is present. This works satisfactorily unless two copies of the same application are running and in this case the application has to be tagged in a unique way. Note that there are two ways of using PKTDRV under a control program. The preferred way is to load it in a DOS session after the control program has been started and then run the application. In this way when PKTDRV asks PKTMUX if it has received a buffer it can be sure the application is in memory and so minimises any delay. Alternatively when an application runs directly under the control program it is therefore not possible to load PKTDRV in the same virtual memory so it has to be loaded under DOS before the control program. It therefore has no certainty that the application is running when it asks PKTMUX if any data has been received so sometimes has to wait until its timer interrupt coincides with the time slice of the application. This can slow things down considerably and may require PKTMUX to have a larger buffer pool in order to cope. 7.4 Listeners and /l Options ---------------------------- One of the problems PKTMUX has to solve is to which application to route packets for which it has no previous knowledge. Examples are ARP requests and calls to previously unused TCP or UDP ports. Experience has shown it is best to send ARP requests to all applications. For TCP and UDP ports the requests can be either for well know services (such as TELNET or FTP) in which case the default is to send it to the first application to sign up for that packet type in the hope that it has a listener for this service. This avoids more than one response to such a request. Alternatively it may be to a port previously notified by the application and in this case it is sent to all applications who use that packet type. This latter technique works provided the application is tolerant of such unsolicited messages. Tests so far indicate that PC-NFS and CUTCP dont mind. However PCTCP and Waterloo TCP are more strict and send back an error message. For TCP this is a RST (reset) and for UDP it is an ICMP Port Undefined message. Since this upsets the service being used such cases are trapped and the error message filtered out. In the PKTSTATS output they are counted under "Ignored: err Resp" and under "Ign" in the "PKTDRV channels:" tables. Note that there is currently no way of preventing such unsolicited messages being sent to an application and the /l options only apply to packets for well known ports. The definition of a well known port is a little vague these days. Originally it was 0-255 but the Unix fraternity officially extended this to 1024 for Unix Standard Services and the current RFC 1106 list goes way beyond this value. As some applications assume this rule in their port usage so PKTMUX designates ports 0-255 as well known and routes them to only one channel. Any other services outside this range are likely to be provided by a specialist server so sending to all should locate it. This may be revised in the light of experience. The various /l options on PKTDRV override the default setting for well know services and indicate where such a request should be sent or not. Options of the form /l indicate this application has servers of this type and /!l indicates it does not. The absence of an /l or /!l option means the application provides all servers but it is used only when no other application has an /l option. The /l option types are implemented as an hierarchy with the specific protocol ports for TCP and UDP taking precedence over the protocols themselves which in turn take precedence over the protocol family (IP). Last in precedence is a general listener. The applications are also searched in reverse order of loading so that a later application can take precedence over an earlier one. The simplest method of making sure the main services such as FTP are found is to load that application first. Where this is not possible then the PKTDRVs for applications that do not support servers over a protocol should be marked as such by an /!l (ie not a listener) type option so that it is avoided when looking for the default. And any application that wants to take over from the default can be marked by an /l (ie I am a listener) type option. Note that requests will be discarded if no listener is found. PKTSTATS will display the listener settings for each channel. 7.5 Port Duplication -------------------- When an application makes a call to a service it specifies the port to which replies should be sent. How this port number is generated is dependent on the application. There is therefore a possibility that two applications could generate the same reply port number. To combat this PKTMUX inspects all reply port numbers in outgoing packets for TCP and UDP and replaces any new and duplicated number by the next one higher, if that is not in use. It also resets the packet header sumcheck if this is being used. Port numbers on incoming packets are similarily mapped. Thus it is possible to run two copies of the same application without any problems of port duplication. However there are two areas that cannot be fixed. One is where the application specifies the reply port via the protocol. For example FTP usually specifies the port to be used for the file transfer via the PORT command in its controlling data stream. Since PKTMUX does not analyse the data going through it this is not noted. There is therefore the possibility that such a port number may be duplicated if two copies of the same application are run. Fortunately tests with the FTP implementations from PCTCP and CUTCP have not shown this to be a problem. The second is where the reply port is a well known port and an example of this is BOOTP. In this case it assumed that any duplicate use of this port is by an application taking over the function this well known port supports. Thus a BOOTP exchange on one channel will be assumed complete when a second channel uses BOOTP. If this is not the case, as it would be if two applications started up at the same time, then hopefully the BOOTP retry mechanisms will recover the situation. 7.6 IP Fragmentation -------------------- IP Fragmentation is a means whereby a large packet is carried through a network whose packet size limit is too small. It is done by simply putting the extra data into the data part of one or more IP packets ie. where you would normally expect the TCP or UDP header to be. The constituent packets of the fragment are linked by having the same IP Identification. PKTMUX notes the channel that the first fragment is sent to and then routes all further fragments with the same Identifier to that channel. This works satisfactorily for most cases but has some potential problems. The first is when the fragments arrive out of order. As PKTMUX needs the first packet in order to get the TCP or UDP header out then any fragment that arrives before this packet will be discarded. Such cases are recorded in the NO FRAGMENT count of PKTSTATS output. The protocol retry mechanisms should retransmit the packet and hopefully the first packet of the fragment will arrive first and everything will be ok. The second is a more difficult problem in that if the same IP Identification is used by two fragmentation sources then PKTMUX has no way of distinquishing between the two. Hopefully this will be very rare and the receiving application(s) should spot that they have the wrong fragments and their retry mechanisms should recover the situation. Note that when fragmentation is occurring then the number of received and copied fragments (excluding the first) is displayed by PKTSTATS. 7.7 Other IP Protocols ---------------------- PKTMUX is only able to multiplex on IP protocols it knows about. These currently are TCP, UDP and ICMP. Any other IP protocol type will be handled correctly provided there is only one channel using it. Multiple usage of another IP protocol will therefore fail. Provided any such protocol had a port mechanism of some form it would be possible add support to PKTMUX if required. 7.8 Channel Management ---------------------- Normally a channel is freed when the application Releases all the packet types is has Accessed. If this does not occur, usually because the application has crashed, then there are two possible cases. The first, and most normal, is where the PKTDRV being used by the application is still running and is a call the PKTSTATS shows it to be Busy. The command: pktdrv /r will reset the PKTDRV and free the channel. The second case is when the PKTDRV is not running. PKTMUX detects this by the absense of any timer interrupts and frees the channel after about two seconds. However this technique fails under a control program such as Windows 3 or DESQview since the DOS session can be locked thus preventing the PKTDRV from sending its timer interrupts. An example is when an area is Selected under Windows 3 for such actions as cut and paste. To overcome this PKTMUX does not immediately free such channels when running under a control program but this gives the new problem that it now has no means of knowing the channel can be freed. Such channels are marked as having Timed Out and this is displayed by PKTSTATS. To reset such a channel use the following command: pktmux /r in a DOS session and this will make all such channels free again. An automatic means of recovery from this situation is provided by the third PKTMUX parameter, Chan_time_out. This is the time in seconds the call stays in a timed out state before being freed automatically. However this should be set with care since if you spend too long on your cut and paste the channel may be freed and your application will fail. One side effect of an application crashing is that it may leave PKTMUX in one of its internal busy states. This is shown by the PKTSTATS /aa output in the line "Busy Flags". If this occurs then PKTMUX will effectively go to sleep. When this is the case then the call: pktmux /rr will also reset these flags and PKTMUX may resume working. It may also crash! 8. Problem Solving ================== This section attempts to suggest how problems with PKTMUX should be tackled. It is worthwhile reading the meaning of the various options and also the Technical Description above in order to ascertain if your problem and its solution is documented therein. Also the section on Bugs/Features and Problem Programs should be consulted. One of the biggest difficulties with PKTMUX is sorting out why something is not working properly. To assist in this the utility PKTSTATS is provided which, when used with the /a option, gives details of what PKTMUX is up to and its various counts. Any count whose name is in CAPITAL letters indicates data being lost or discarded because there is a problem and the following attempts to explain what they mean. Note that such counts are usually only displayed when they have a value so their absence indicates all should be well. The first class of problems is where PKTMUX simply does not work with an application. The first test is to run the application on its own having loaded PKTMUX with the /x option. Normally in this situation PKTMUX would pass data direct to the application but with the /x option (multiplex) it copies data to its buffers and uses its multiplexing facilities thus checking if they can cope with the application. If this fails then the application probably has some quirk that confuses PKTMUX. If it is a standard application that works elsewhere then you may have a networking set up that PKTMUX cannot cope with. A second test is to add the /c (copy) option to each PKTDRV. This causes it to copy the data sent to the network into its own buffers and this has been known to cure problems related to the use of upper and/or EMS/XMS memory. Where an application works with PKTMUX as above but not in conjunction with other applications then it is worth trying different combinations and seeing what does and does not work. This may isolate one application as being the problem or show a certain loading order to be the cause. Possible reasons are that a listener for a well known port is being usurped by another application (see PKTDRV /l option) or that one application simply prevents any other from running. Check the Bugs/Features and Problem Programs section for any indication of problems. It is also worthwhile checking if anyone else has a similar problem. Another class of problems is where PKTDRV is marked Busy when it should be Free or there are no Free PKTMUX channels. This is usually due to applications failing in some manner and the means of recovery are described in the Channel Management part of the Technical Description section. The final, and probably the largest, class of problems is where everything works for a while then things start going wrong. Using PKTSTATS can give an indication of the cause but in general it is only those cases where the problem can be reproduced that a solution can be found with any degree of certainty. Note that PKTMUX depends on probability for its successfull working and when the odds are wrong it will fail for no apparent reason. However for regular failures the suggestions below may help. A general technique is to run PKTSTATS /a and note the various counts. Then run the application(s) that cause the failure and subsequently run PKTSTATS /a again and note which counts have increased. This should give a clue about whats going wrong. A possible reason for an application not working properly is that it, or PKTMUX, has run out of buffers with which to receive data. This is especially prevalent under a control program such as Windows where applications do not get enough CPU time to process their data. Details of buffer usage are given in the "Buffers:" table and for the case of PKTMUX running out of buffers the count "PKTMUX NO BUFFER" is given in the "Queues" line. Increasing the number of buffers used via the /1 to /9 options on PKTMUX should solve this one. Detecting that the application is running out of buffers is more difficult since PKTMUX may not be able to deliver the data for a variety of reasons. This can be isolated by running the application on its own over PKTMUX (without the /c option). As it has only one channel operative PKTMUX just passes all calls directly to the application. Any refusal by an application to supply a buffer causes PKTMUX to copy the data into its own buffers. This is shown in the Copied count on the "Recv total" line and the PKTDRV channel counts. The only solution is to increase the applications buffers if this is possible. When PKTMUX has more than one channel Busy, and has to wait to pass received data to an application, this is also recorded in the PKTDRV table. The wait reason is either no buffer available from application (Buff) or, under Windows 3 or DESQview only, the application was not in memory (App). The latter is especially prevalent for background processes paticularily when a foreground process requires a lot of CPU. When it has to wait PKTMUX has to decide whether to try again later or discard the buffer. The latter is only done when PKTMUX has several channels that are actually moving data at the same time and it has insufficient buffers to meet all their demands. The "LOST" count in the "PKTDRV channels:" table would be incremented in this instance and again increasing the number of PKTMUX and/or application buffers is a possible solution. It may be that, especially under Windows 3 or DESQview, the PC has simply not enough horsepower to cope with the communications load as well as any processing in progress at the same time. Thus the application(s) are not processing the received data fast enough to cope with the incoming rate. Alternatively it may be an application, such as TRUMPET, that refuses to accept packets when it knows it is not expecting data. Another reason that data may be discarded is when there is no listener for the service that is being requested. The count "NO LISTENER" is incremented in the "Recv ignored reasons" list. There are several possible reasons for this but in general it is because the /l and /!l options on PKTDRV calls dont leave a suitable listener. Note that this count will not be incremented if there is a listener available but it does not support the service requested. In this case an application that supports the service must be run with a PKTDRV that routes requests for the service to it by using the /l or /!l options. A final reason for discarding data is when an IP Fragment arrives out of order. If it arrives before the first fragment then PKTMUX has no way of knowing to which channel it belongs and so discards it and increments the count "NO FRAGMENT" in the "Recv ignored reasons" list. The subsequent retry should overcome this problem provided that this time the first fragment arrives first. 9. Bugs/Features and Problem Programs ===================================== The following list of situations that need special action. It is based upon limited experience so only covers a few cases at present. The 16 bit BICC ethernet cards require the /c option on PKTDRV when running under a control program and dont work with WINPKT. The /c is not required when under DOS but is needed when a protocol stack such as PCTCP is run under DOS for a Windows 3 application such as Vista eXceed X Windows. When the X Window server Vista eXceed is running over PCTCP it must have enough buffers allocated via the ETHDRV command otherwise the call will be reset at intervals and thus fail. An ETHDRV call similar to the following is recommended: ethdrv -t 10 -p 20 Further details are given the Vista eXceed and PCTCP manuals. It may also be necessary to increase the PKTMUX buffer allocation when using this or other X Windows servers. PKTMUX will not work with the packet driver version of Novell IPX if the PKTDRV is using Interrupt 64. This is because Interrupt 64 is a Novell API and so from v1.1 onwards it is not allocated by default. PKTMUX tends to operate a lot with interrupts disabled. This may cause problems with time critical communications methods such as asynchronous links using SLIP. TRUMPET refuses to accept packets when it is waiting for user input and expects no more data. This can cause PKTMUX to run out of buffers under heavy loading. In this case it is recommended that the /d option be added to the PKTDRV used by TRUMPET. When PC-NFS is in use alongside PCTCP then a TSR, such as the MOS2 3270 emulator, is unable to run when the PCTCP FTP program is waiting for a command. The problem does not occur with the CUTCP FTP so it appears to be related to the wait loop used by the PCTCP FTP when waiting for a command. There have been reports of PCNFS and PCTCP not working together over PKTMUX. As it works for other users there is obviously some other factor that is not currently appreciated and investigations are continuing. 10. Differences in PKTMUX versions ================================== 10.1 Version 1.0 ---------------- First release to prove that the techniques worked. Note this version does not support IP Fragmentation. 10.2 Version 1.0a ----------------- PKTMUX now checks that it is loading on top of a real Packet Driver and aborts if it finds its actually a PKTDRV. 10.3 Version 1.1 ---------------- The programs from this version must not be mixed with those from version 1.0 as they are incompatible. In searching for a Packet Driver PKTMUX now checks the interrupts to see if PKTMUX or PKTDRV is already loaded and aborts if one is. Similarily if the Packet Driver interrupt is specified this is checked to see if it is a real Packet Driver. This is to prevent multiple loadings of the system. The option /o (override) has been added to PKTMUX to override this restriction. PKTMUX now starts by default with 2 channels. PKTDRV options /f and /!f have been added to force a PKTDRV to the Free or Busy state. The PKTSTATS output has been changed to reflect this. PKTDRV no longer uses Interrupt 64 by default as this clashes with a Novell API. IP Fragmentation was not supported in previous versions. It is now supported within limitations (see Technical Description). The buffer management system has been improved especially with regard to discarding unwanted packets. The option /d (drop) has been added to tell PKTMUX to drop all packets for which the application has no buffer rather than keeping them until the application has space. The same option is available on PKTDRV which works on a per channel basis. The number base of buffers has been also been increased in some cases. A bug in the Packet Driver handle mapping when PC-NFS was in use has been fixed as has one in the area of duplicate handles. A bug in the mapping of ICMP packets onto channels has been fixed. The bug caused ICMP packets containing IP data to be sent all channels. PKTMUX v1.0 used a time out mechanism to determine whether a PKTDRV and its application had been forcably terminated under a Windows or DESQview environment. Unfortunately this mechanism was also triggered when the window was Selected under Windows 3 for actions such as cut and paste and caused the channel to be closed down. This has been changed in v1.1 so that in these circumstances a channel will not be closed down. The option /r has been added to PKTMUX to reset such channels otherwise they are permanently busy and there is no PKTDRV to reset them. A third parameter has also been added to PKTMUX to reset such channels after a given time. ARP Request Broadcasts are now sent to all channels. The /la option is therefore no longer needed. The handling of Broadcast packets has also been improved so that only those ARP requests that are not for this address are discarded. BOOTP did not work for second and subsequent channels because it replies on a well known port and this only went to the first listener. This has now been changed and the response is sent to originator of the BOOTP provided no other channel has done a BOOTP in between. If this occurs then the timeout and retry mechanisms should recover the situation. The problem solving section has been improved and the /v option (multiplex) added to PKTMUX to assist this process. 11. Support =========== PKTMUX is supplied free and is supported, within the limits of its specification, for all users at RAL on IBM PC and PS/2 computers and near clones. Note that support is confined to bugs in the programs and clarification in the documentation of the systems limitations. Users outside RAL are requested in the first instance to obtain copies and help from their normal support sources. Academic user support organisations may seek help from RAL but the latter will only be given on a 'best endeavours' basis. There is no support for other organisations other than by private arrangement with the author. Updates of the software may be file transferred from the binary file PKTMUXxx EXE (xx being version number without a point - currently 11) on the RAL IBM mainframe (UK.AC.RL.IB on JANET, IB.RL.AC.UK on the Internet) disc PCSOFT 192. TCP/IP users of Anonymous FTP should CD to PCSOFT.192 and binary GET PKTMUXxx.EXE. Executing the file will produce the program and documentation. Further details of how this is done can be obtained by email from the author. Bug reports or problems should be reported, ideally by email, to Graham Robinson: Via JANET : GWR@UK.AC.RL.IB G W Robinson Via Internet : GWR@IB.RL.AC.UK Atlas Centre UK Telephone : 0235 44 5636 or 6391 Rutherford Appleton Laboratory International: +44 235 44 5636 Chilton, Didcot Oxon,OX11 0QX,UK 12. References ============== The RAL LOADSYS system version 1.4 is held in file LOAD14 EXE on PCSOFT 192 as detailed above. The RAL MOS2 IBM 3270 emulator version 2.3 is held in files MOS23 EXE, MOS23X EXE and MOS23Y EXE on PCSOFT 192.